All inspection handlers would not be properly disposed of because inspectionHandler is a global variable (L901) and each panel.disposed.connect() callback (L967-969) references this global variable, not the specific handler instance created for that panel. So when notebooks are closed only the most recently created handler gets disposed while previous handlers remain in memory with associated resources not being freed.

Test by opening multiple notebooks then closing any other than last created notebook, note that only last handler gets disposed of.

Tracking handlers per panel and ensuring correct disposal of all handlers would fix this.

Wondering is this is a real issue in practice.

In Jupyter Notebook there is only one notebook at a time on the page, which actually should never really be disposed. So there should be one inspection handler instantiated on the page.

This code snippet was inspired by the upstream implementation in JupyterLab, but it could be cleaned up or simplified a bit to only handle the Notebook use case.

setSource() can be called before inspectionHandler is initialized (L932), for example during app startup, causing undefined access when app.shell events fire before any notebook is opened.

To test, add logging inspectionHandler at L975, launch notebook server without opening any notebooks, refresh the browser page while monitoring the logs, see inspectionHandler is undefined.

While this doesn't break functionality (opening a notebook later initializes the handler), it puts the inspector in an invalid state during startup and could cause issues if other components try to use it during that window.

Adding a null check to setSource() or declaring inspectionHandler as nullable and initializing it to null would fix this.

This mutates kernel messages, other extensions / components would receive the modified version missing pager payloads. Based on my research JupyterLab's codebase as of now does not mutate kernel messages in other places. For example, @jupyterlab/outputarea copies the message.

Would it be possible to accomplish the same without mutating the kernel messages? For example watch cell output model changes to detect pager payloads during cell execution and route them to the down area before normal output rendering?

Indeed, maybe there is a way to check the outputs directly.

Need to check if this will have any visual side-effect too (for example the output is rendered and then removed).

For example, @jupyterlab/outputarea copies the message.

I looked a bit more into this. While we could set up handlers to check the output area model, information about the message gets lost when it's added to the output:

const output: nbformat.IOutput = {
  output_type: 'display_data',
  data: (page as any).data as nbformat.IMimeBundle,
  metadata: {}
};
model.add(output);

And there doesn't seem to be any easy way to know if an output is the result of pager information.